Skip to content
This repository was archived by the owner on Feb 24, 2026. It is now read-only.

feat: generate params for maestro based on envs#504

Open
JulienLeal wants to merge 3 commits intoexpo:mainfrom
JulienLeal:feat/add-env-maestro-parameter
Open

feat: generate params for maestro based on envs#504
JulienLeal wants to merge 3 commits intoexpo:mainfrom
JulienLeal:feat/add-env-maestro-parameter

Conversation

@JulienLeal
Copy link
Copy Markdown

@JulienLeal JulienLeal commented Jan 24, 2025

Why

This change enables secure and flexible test configuration by allowing dynamic environment variables to be passed to Maestro flows via command-line parameters. This addresses the need to:

  • Avoid hardcoding sensitive values like credentials in test files (GitHub/community discussions around secure test configuration)
  • Support environment-specific configurations in CI/CD pipelines
  • Align with Maestro's parameter handling best practices (documentation reference)

Example Scenario

Injecting API keys dynamically in CI:

build:
  name: Build and Run Secure Tests
  steps:
    - eas/build
    - eas/maestro_test:
        inputs:
          flow_path: .maestro/auth-tests/flow.yaml
          env: 
            AUTH_API_KEY: ${PROD_API_KEY}  # From CI secrets

Corresponding Maestro flow (.maestro/auth-tests/flow.yaml):

appId: com.example.app
jsEngine: graaljs
---
- evalScript: ${console.log("API Key:", AUTH_API_KEY);}

How

Implemented support for passing environment variables through -e flags following Maestro's external parameters pattern

Test Plan

yarn test src/steps/functionGroups/__tests__/maestroTest.test.ts

@JulienLeal
Copy link
Copy Markdown
Author

bump @szdziedzic @sjchmiela

@sjchmiela
Copy link
Copy Markdown
Contributor

Hey, thanks. Wouldn't it be easier to use MAESTRO_* variables that are automatically exposed within the flow?

https://maestro.mobile.dev/advanced/parameters-and-constants#accessing-variables-from-the-shell

I see one problem which is that we currently don't apply templating/interpolation to env step attribute, but this is something we're planning to do soon either way. Then, instead of having two env on a call to eas/maestro_test (top-level and under inputs) you'd do (in a Custom Build):

build:
  name: Build and Run Secure Tests
  steps:
    - eas/build
    - eas/maestro_test:
        env:
          MAESTRO_AUTH_API_KEY: ${ eas.env.PROD_API_KEY } # From CI secrets
        inputs:
          flow_path: .maestro/auth-tests/flow.yaml

On a separate note I would recommend considering moving to EAS Workflows. You could orchestrate multiple builds on different platforms, run Maestro tests conditionally, use different EAS Environments for different jobs and lots more.

@JulienLeal
Copy link
Copy Markdown
Author

@sjchmiela I didn't think this option. I'll test right now, thanks <3

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants